前言

今天要探討關於 QUIC 的地址驗證(Address Validation) 機制，這個機制主要是要防止一些流量放大攻擊(traffic amplification attack)，攻擊者可能發送一個封包給 Server，但來源地址是填入受害者的地址，導致 Server 會回傳一個更大的封包給受害者，進而達到流量放大的效果。

要防止流量放大攻擊的主要措施就是想辦法驗證對端(endpoint)宣稱的地址是否有能力接收封包，Address Validation 通常在兩個時機會觸發，一個是前幾天討論的建立連線(Connection Establishment)期間，另一個就是之後會提到的 QUIC 的另一個重要特色，連線遷移(Connection Migration)的期間。

建立連線時的地址驗證

一般建立連線的流程隱式的做了地址驗證的機制，如果 Server 端收到的封包資料使用前面 Handshake 流程得到的金鑰加密，代表說 Client 成功處理了 Initial packet，這種情況下 Client 就不會是被偽造 address 的受害者，畢竟如果是受害者，應該沒有 Handshake 產生的金鑰，也不會回傳加密後的資料。

而且如果 Client 回傳的封包的 Destination Connection ID 是填入 Server 所選的 Source Connection ID 的話，也算是進一步證實 Client 的地址是合法的，且 Client 端的確有跟 Server 交互資料的需求。

對於 Client 驗證 Server 來說，可以使用 Client 發出的第一個 Initial packet 中的 Destination Connection ID 來驗證 Server 回傳的封包，驗證 Server 是原本要建立連線的對象。

避免流量放大攻擊的措施

為了避免流量放大攻擊，Server 端在還沒有驗證 Client 地址的情況下必須要計算其傳來封包的 payload 大小，Server 回傳的封包大小不能超過從 Client 收到的 payload 大小的三倍，這個措施可以在某些程度緩解遭受流量放大攻擊時的受害規模。

Client 端的 Initial packet 也要求至少要有 1200 bytes 的 payloads，如果小於 1200 bytes 則必須要填充 PADDING frame 達到最低限制。

在 Handshake 之前就驗證地址

上面介紹的驗證方式是指當成功建立連線，就隱式的完成地址驗證，但 QUIC 想到有些 Server 想要在真正開始建立連線前就驗證對方的地址，這時就會導入 token 的機制來在 Handshake 完成之前先驗證對方的地址，這個 token 也可以用於後續的 0-RTT 連線。

傳送 token 會使用 Retry packet，在明天的文章我們會介紹 QUIC 如何利用 Retry packet 與 token 在還沒有正式建立連線時就驗證對方的地址。

Retry packet 傳送 token 是發生在 Handshake 流程中，前幾天關於 Connection ID 的協商介紹其實並不完善，在後天的文章中我們也會介紹導入 Retry packet 後雙方如何協商出 Connection ID，其實也只是多了 1~2 個步驟而已。

reference

• RFC9000